Big one!

Give me some time to review but will priortize

Hey! Any luck to be checked soon?

Testing now

Quick question on the Stop hook output format.

On approve, the hook outputs {} and exits 0, which means the turn just completes normally. But nothing triggers the transition to Default mode or submits "Implement the plan" like the TUI does. So approval is effectively a no-op from Codex's perspective, right? The user would still need to manually switch modes and kick off implementation.

Quick question on the Stop hook output format.

On approve, the hook outputs {} and exits 0, which means the turn just completes normally. But nothing triggers the transition to Default mode or submits "Implement the plan" like the TUI does. So approval is effectively a no-op from Codex's perspective, right? The user would still need to manually switch modes and kick off implementation.

Short answer: yes for the hook protocol / codex exec, but not for the interactive TUI/app.

Why approval is a no-op at the hook layer

• plannotator/apps/hook/server/index.ts:1019-1020 prints {} on approve.
• In Codex, the Stop hook output has no special “approved” field. The universal schema is just continue, stopReason, suppressOutput, and systemMessage, with continue defaulting to true: codex/codex-rs/hooks/src/schema.rs:57-65 and codex/codex-rs/hooks/src/schema.rs:513-514.
• parse_stop() only derives should_block from decision:"block"; {} therefore means “continue processing, don’t block, don’t stop”: codex/codex-rs/hooks/src/engine/output_parser.rs:176-193.
• The core turn loop only has special handling for should_block and should_stop. If neither is set, it just falls through and completes the turn normally: codex/codex-rs/core/src/codex/turn.rs:540-567.

So if you mean the Stop hook itself, then yes: approval is just “let the turn finish.” It does not itself switch to Default mode or inject Implement the plan.

Why that is not the whole story in the TUI/app

• After a task completes, the TUI calls maybe_prompt_plan_implementation(): codex/codex-rs/tui/src/chatwidget.rs:2430-2432.
• That method checks that the current mode is Plan and that a plan item was seen this turn, then opens the implementation prompt: codex/codex-rs/tui/src/chatwidget.rs:2448-2472.
• The TUI defines PLAN_IMPLEMENTATION_CODING_MESSAGE as "Implement the plan." and, on “Yes,” submits it in Default mode: codex/codex-rs/tui/src/chatwidget.rs:248-251 and codex/codex-rs/tui/src/chatwidget.rs:2475-2484.
• There is an explicit test for this behavior: codex/codex-rs/tui/src/chatwidget/tests/plan_mode.rs:30-39 asserts the submitted text is Implement the plan. and the collaboration mode is ModeKind::Default.

Conclusion

• In codex exec: your statement is correct. Approval is effectively just normal completion, so the user would need to manually start implementation.
• In the interactive TUI/app: not quite. The hook approval itself is still a no-op, but once the approved plan turn completes, the TUI’s normal post-plan flow should offer “Implement this plan?” and submit Implement the plan. in Default mode if the user accepts.

I'm trying one thing with the app server. If it doesn't work, we'll merge this approach.

Releasing this today